"XPNET 3.1 Interim Bug Fixes (IBFs) and Enhancements - PWS" SCR # Change Description ----- ------------------ SCR #3313 Files unique 08-MAR-06 for XPNET 3.0 Accelerates -------------- ----------------------- XPNET.ocaALL - u30oca.ocaA00as all TNS objects on subvol XPNET.ocaBUILD - u30oca.ocaB00as called by all OCA routines XPNET.ocaAPPL - u30alib.oca00as APPLIB XPNET.ocaNET - n30base.oca00as NETWORK XPNET.ocaNETAD - n30audr.oca00as NETADRD XPNET.ocaNCP - s30ncp.oca00as SVNCP XPNET.ocaNCPI - s30ncpi.oca00as SVNCPI XPNET.ocaNLIB - n30nlib.oca00as NLIB XPNET.ocaPREG - s30pre.oca00as PREGEN XPNET.ocaSKELB - n30sutl.oca00as SKELB XNLIB.ocaSMPL - u21smpl.oca00as (sample OCA file) XNLIB.ocaXNLIB - u30xlib.oca00as XNLIB Files unique for XPNET 3.1 Accelerates -------------- ----------------------- XPNET.ocaALL - u31oca.ocaA00as all TNS objects on subvol XPNET.ocaBUILD - u31oca.ocaB00as called by all OCA routines XPNET.ocaAPPL - u31alib.oca00as APPLIB XPNET.ocaNETAD - n31audr.oca00as NETADRD XPNET.ocaNCP - s31ncps.oca00as SVNCP XPNET.ocaNCPI - s31ncpi.oca00as SVNCPI XPNET.ocaNLIB - n31nlib.oca00as NLIB XPNET.ocaPREG - s31pre.oca00as PREGEN XPNET.ocaSKELB - n31sutl.oca00as SKELB XNLIB.ocaSMPL - u31smpl.oca00as (sample OCA file) XNLIB.ocaXNLIB - u31xlib.oca00as XNLIB Files for XPNET 3.0 & 3.1 Accelerates --------------- ----------------------- XPNET.ocaAUDP - u30audp.oca00as AUDPRO XPNET.ocaPATH - n21path.oca00as PATH XPNET.ocaPWR - n21pwr.oca00as PWR XPNET.ocaPWS - n30pws.oca00as PWS XPNET.ocaQFI - n30qfi.oca00as QFI XPNET.ocaQFILD - n30qfi.ocal00as QFILOAD XPNET.ocaTCPC - n30tcpc.oca00as TCPCLI XPNET.ocaTCPS - n30tcps.oca00as TCPSRV XPNET.ocaUDP - n30udp.oca00as UDP SCRIBE.ocaEMSP - n30empp.oca00as EMSPERUS Reference: Internal, case 408953 Symptom: None. Problem: None. Change: Developed TACL routine files which can be used by customers to accelerate TNS objects for Itanium machines using the HP Object Code Accelerator (OCA) utility. See the list of files above, with the respective name of the object(s) they accelerate. Implementation: Install the new files on the XPNET, XNLIB and SCRIBE subvols as indicated. To OCA-accelerate objects on the XPNET subvolume, the OCAALL file can be run to accelerate all the objects it can find (required and optional) on the XPNET subvolume or each individual object can be accelerated separately using its respective OCA file. Note that OCAALL first performs a checklist of the files it can accelerate and then invokes the respective individual OCA files, as necessary, to OCA-accelerate each module. On the SCRIBE subvolume, run the OCAEMSP file to accelerate the EMSPERUS object. If the XNLIB object is used, run the OCAXNLIB file on the XNLIB subvolume to accelerate the XNLIB object. The OCASMPL TACL routine file can be used for accelerating TNS user applications which use the XNLIB run-time library. Just FUP DUP OCASMPL to the location of the object that you want to accelerate, modify the DUP'ed macro file to point it to the correct object file and create the correct target file and then run it from the TACL prompt. You can add options to suppress warnings as necessary. The TACL routines are designed to create a new object of the same name with an "A" appended to the end of the object filename (e.g. when the SVNCPI object is accelerated, a SVNCPIA accelerated object is created). If the OCA acceleration is successful, the original object is named to a ZZOCnnnn file and the "A" file is renamed to the original object file. You can purge the ZZOCnnnn file that was created as procedures warrant. Stop and restart the object if necessary. The HP OCA utility is available with the H-series NonStop OS for Itanium machines. Note also that the HP OCA utility is available with the G-series NonStop OS starting with G06.27. OCA accelerating an object on a non-Itanium system does not modify the performance of the object on that system, but does allow the object to run with optimal performance once it is moved to an Itanium system. Dependencies: None. SCR #3583 --XPNET 3.1-- EOF LAST MODIFIED 18-JUN-12 OCAPATH - n21path.oca01as 6928 22JUN2012 14:16 OCAPWS - n30pws.oca01as 16430 22JUN2012 14:24 OCAQFI - n30qfi.oca01as 7410 22JUN2012 14:28 --XPNET 3.0-- EOF LAST MODIFIED OCAPATH - n21path.oca01as 6928 22JUN2012 14:16 OCAPWS - n30pws.oca01as 16430 22JUN2012 14:24 OCAQFI - n30qfi.oca01as 7410 22JUN2012 14:28 OCAAPPL - u30alib.oca02as 11272 26JUN2012 13:04 OCAMQSI - n30mqsi.oca01as 7582 26JUN2012 13:16 OCANCP - s30ncp.oca01as 11254 26JUN2012 12:54 OCANCPI - s30ncpi.oca01as 14368 26JUN2012 12:58 OCANET - n30base.oca01as 6708 26JUN2012 12:49 OCANETAD - n30audr.oca01as 6696 26JUN2012 12:45 OCANLIB - n30nlib.oca01as 7082 26JUN2012 12:52 OCAPREG - s30pre.oca01as 6852 26JUN2012 13:08 OCASKELB - n30sutl.oca02as 11510 26JUN2012 13:13 Reference: 1207310 Symptom: - When runing OCA tacl routines provided by ACI, amessages similar to the below log and the job aborts. PATH object is being accelerated with OCA. OCA /out $S.#OCA.PATH, name / PATH, output_file PATHA, obey ZZOCA07 *** ERROR *** OCA failed with completion code 1 See $S.#OCA.PATH for error information. - Spooler output from the OCA job contains output similar to the below. *** Warning 15: Procedure REL3_DLIBB69_20NOV95 at offset 01547 in file PATH inherits register 7. *** Warning 15: Procedure DUMP at offset 03144 in file PATH inherits register 7. Problem: HP modified their OCA product causing new warnings. HP solution 10-110309-6569 already exists and they are considering a fix (see that solution for details). HP looked at one of our object files and said these particular warnings were safe to ignore. Change: Added "INHERITSR7" statements to the OCA files (listed above) to work around the issue while HP decides whether to make a fix. Implementation: Install the new OCA files on the XPNET subvol. If previous executions of OCA failed, purge the intermediate "xxxA" files (i.e. PATHA, PWSA, QFIA). Execute the new OCA files. Dependencies: None. SCR #3748 PWS - rel3^ver0^pws07^181129 29-NOV-18 PATHTPLS - $data01.n30pws.pws03ps PATHTPLO - $data01.n30pws.pws03po Reference: 2793513 Symptom: The client sends a message to PWS which is sent to XPNET. The client gets a zero length reply and the response is queued at the XPNET station. Problem: The client is using the new SERVERCLASS_SENDL_ call. The maximum reply size parameter is set to a value larger than 32,767. PWS uses a signed integer for the parameter which causes the maximum reply size value in PWS to be a negative number. PWS thinks the client is asking for a zero length response. PWS replies immediately with a zero length response and doesn't read the response from XPNET. Change: Altered PWS to determine that the maximum reply size is invalid. If invalid, PWS replies to the client with an error 21 ( illegal count specified ) and generates event message 1341 indicating that the maximum reply count is invalid. Implementation: Restore the PATHTPLS and PATHTPLO files to the XPNET subvolume. Remake the XPNET templates using SCRIBE.TMPLMAKE, and then remake all EMS templates using the SCRIBE.GOINST macro. Install the new PWS module, Stop and restart the PWS process. Dependencies: None. Code Review: CR-XPNET-52